-
Notifications
You must be signed in to change notification settings - Fork 84
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add (insecure!) Bitcoin headers over DNS support #138
base: master
Are you sure you want to change the base?
Conversation
Disabled by default. Use this with Matt Corallo's https://bitcoinheaders.net/ service.
Nice! I understand not providing a default value for the dns-data provider makes sense but citing bitcoinheaders.net in the command help or in the readme would make the user not knowing the strategy able to use it and inform himself/herself |
Yeah, I think before this is actually merged it should be easier to use. But first, I want to figure out how to make this more secure. It should have some kind of minimum work threshold, or signature check. Matt's service is signed with DNSSEC. But there's no good way to validate DNSSEC signatures client-side. The issue with a minimum work threshold is for older timestamps you need to validate a lot of headers to get a reasonable amount of total work. ASICs have gotten much better over the years. |
|
||
addr_bytes = addr.packed | ||
|
||
if addr_bytes[0:2] != b'\x20\x01': |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Please dont check this, just ignore it. The block header is self-validating by PoW :p
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actually, that's kinda what I'm doing with that check: if some addresses are added, without the right prefix, they'll be ignored on the off chance that the remaining addresses are a valid block header.
But yeah, I don't actually check PoW in this version of the code so...
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hmm, but I kinda wanted the ability to change the prefix arbitrarily on the server side without it impacting clients.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ah! Well, if you're going to do that, you should document that.
So difficulty as of Sept 2016, when OpenTimestamps in its current form was released, was 220 billion. Currently it's 64 trillion. So 291 blocks worth of 2016 blocks are equivalent to one block today. Older timestamps do exist, as other timestamps can be converted to OTS format. But they're pretty uncommon. By 2019 difficulty had risen to 6 trillion, which is already ~1/10th of the current difficulty. In terms of a dollar value, the current 6.25 BTC block reward is worth $230,000 today. So one 2016 era block would cost $790 in terms of lost revenue to make. It's probably good enough to just have a sum difficulty target, and query block headers (in parallel) until that target is reached. One or two current-era blocks is probably fine: for use-cases where someone would actually spend ~$200k to fake some timestamps, you're probably checking more carefully than with DNS anyway. It also wouldn't be a bad idea to do this via a timeout: fetch as many headers as you can in, say, 5 seconds, even if you've gotten more than the target amount. We can cache headers of course too, so this would help with subsequent validations too. |
Disabled by default.
Use this with Matt Corallo's https://bitcoinheaders.net/ service.